Today's telecommunications systems continue to grow in scope and complexity at a very rapid pace. One of the enablers of this growth is the availability of low cost memory and processing power, which has in turn fostered the development of a new generation of telecommunication protocols, like SIP (Session Initiation Protocol) and SDP (Session Description Protocol). These future-oriented protocols are ASCII (American Standard Code for Information Interchange)-based, extensible and more human readable than earlier protocols where machine efficiency at runtime was valued higher than programmer productivity.
These new protocols carry much more information about the telecommunications services they support than older protocols, and a great deal of flexibility in tailoring a system to specific applications arises from the ability to modify the data in the protocol messages in very specific ways. Since protocols like SIP and SDP are ASCII-based, the data lend themselves to modification by end-users, specifically the technicians responsible for network engineering and planning. In the past, the use of “complex, binary-based” protocols would have required engineering design by the manufacturer to implement such customization.
Some telecommunications systems have traditionally incorporated an optional, integrated BASIC (Beginner's All-purpose Symbolic Instruction Code) interpreter for special applications. As an independently running scheduled process within the system, a BASIC program could send and receive inter-process messages from a CTI (Computer-Telephony-Interface) element within the system to control call processing for specialized applications which might otherwise have required the use of an external host computer. Access was also provided from BASIC to some OS (Operating System) controls, which allowed the manufacturer to implement bug fixes to released software. These manufacturer-provided BASIC programs could relieve symptoms of some types of bugs until a new software package was released to correct the problem.
Since BASIC is an easy-to-use higher-level language especially well suited to processing strings of ASCII characters, it is natural to consider its use for implementing customized modification of SIP and SDP message data either by end-user technicians or by the manufacturer. An example of a useful modification would be in changing data within an SDP “offer” depending on the time-of-day in order to reduce network loading during high traffic periods. This works because the SDP protocol carries information related to the bit-rate required by a media session.
See FIG. 1. The method of interaction between a BASIC process 10 and other system processes 20 is one in which BASIC is an independently running process scheduled by the System Scheduler 5 and sending and receiving inter-process messages (IPMs) 30 to other elements of the system. Such a method is both awkward and inefficient when applied to applications such as telecommunications protocol processing. Any real-time system software 20 that needs to send information to a BASIC process 10 must send it an IPM 30 and then wait for a response, while still accepting other real-time event input.
The requirement to wait for a response while still accepting other event input arises from the fact that telecommunications systems must process data in real-time, and the response from BASIC could be delayed significantly if BASIC is running as an independently scheduled process. A more straightforward interface would allow BASIC to be invoked as a simple function call in-line at the exact points where its processing is desired. This would also avoid the processing overhead associated with scheduling and IPMs.